Models are often used to help visualize concepts by using symbolic representations. Models may include a group of objects, entities, properties, or attributes. For example, a model may be a category of type “planets.” An object within the model may be a specific planet, such as Earth. Properties or attributes within the object may be characteristics, such as size, population, or relative location.
It is often desirable to compare two models to determine any differences between the models. Comparing two different models can help to ensure that the models are synchronized and semantically valid at all times. Existing tools are available that compare different models and identify the differences between the models. For example, a comparison tool called COMPLETE COMPARE™ (available from CA, Inc.) provides one way of comparing models. Previous architectures of the COMPLETE COMPARE™ comparison tool represented the comparison of two models in a set of ‘C’ (the programming language) structures. These structures maintained the memory address of the two models being compared, and a flag indicating the state of equality between them. Then, the COMPLETE COMPARE™ comparison tool displayed the comparison data. In order to synchronize the models, the user designated data in one model that the user wanted to import into the second model. The changes requested by the user were incorporated in an asynchronous or batch mode, in which the changes were held in a script and executed at the end of the comparison process.
This approach often suffered from side-effects. Side-effects are encountered during the act of bringing data into a target model (e.g., in order to synchronize it with another model). Since side-effects did not become immediately visible to the user in real-time, as the user was indicating the desired changes, this often resulted in changes that the user did not intend. In other cases, side-effects might cause a violation of modeling rules and cause certain actions to fail or result in an invalid model.